The popularity of the Internet has given rise to e-commerce. As illustrated in FIG. 1, many consumers 102 enjoy the convenience of shopping at home via websites 104 such as Yahoo!, Amazon.com and eBay, as well as on-line banking via websites provided by banks such as Citibank. Many other activities that formerly required live interactions either in person or via phone can be conducted on-line, such as applying for car or health insurance, buying and selling stocks, etc. via the Internet 106.
Such on-line activities typically require the exchange and storage of personal information such as credit card numbers and banking information. Accordingly, consumers want to be able to trust that the websites 104 are secure from on-line vulnerabilities, such as the ability for hackers to gain access to their personal information.
The inventions and technologies described in co-pending U.S. patent application Ser. Nos. 10/113,875 and 10/674,878, the contents of which are incorporated herein by reference in their entirety, have dramatically advanced the slate of the art of vulnerability detection, assessment and management. For example, these co-pending applications describe techniques for performing vulnerability scans of websites, and hosting and controlling the contents of a mark in accordance with the scan results that indicates to visitors of the website how safe the website is. These vulnerability scans aim to duplicate and/or exploit methods known to be used by hackers to attempt to gain unauthorized access to the devices and systems of the website. Nevertheless, areas of potential improvement exist.
Websites such as 104 are accessed by client software programs over the Internet via a protocol known as Hypertext Transfer Protocol (or HTTP). Using an HTTP request, a client can ask for specific content from a website and/or send user data to the website. Per the specification of the request, the website generates content and returns the content to the client via a corresponding HTTP response. A web browser (e.g. Internet Explorer) is the most common example of an HTTP client. Web browsers make HTTP requests when users type in URLs or click on links or submit forms present in the content of the website. In the specific case of submitting a form, information keyed into the form by the user is included with the HTTP request. When generating content for a response, websites often dynamically construct code based on an HTTP request; and the code is executed by a corresponding interpreter. Dynamically constructed SQL statements executed by a relational database are the most common example, but any other language and interpreter including Ruby, PHP, PERL, etc. can serve.
An HTTP request has a defined structure with designated locations in the structure for carrying various types of information, including user data. By inspecting website content or observing HTTP traffic, a hacker can deduce specifically useful incarnations of the HTTP request structure that can be used to submit unauthorized and/or potentially harmful input to the website.
For example, SQL injection is used by hackers seeking to gain unauthorized access to a website's data servers by embedding executable SQL code into SQL statements that are dynamically constructed by the web application. Depending on the nature of the statements being constructed by the web application, various injection techniques are applicable. All of these techniques focus on breaking out of a SQL statement, inserting an augmentation of the broken statement or inserting an entirely new statement, and optionally breaking back into the remaining statements of a statement block. Effectively, this approach splices foreign SQL code into the target system's constructed SQL statements. If this splice is successful, a hacker can gain unauthorized access into a website's databases and other systems.
Conventional vulnerability scans attempt to inject SQL statements and analyze the resulting content of output from a target system. This content analysis can be used to discover database vendor type disclosures, information about an underlying relational schema, or actual data contained in a schema. Detecting evidence of a vulnerability through content inspection is generally conclusive. However, the failure to detect evidence of a vulnerability through content inspection is not conclusive. A target system may still, indeed, be vulnerable to SQL injection attacks even if the content of the output does not indicate this.
Accordingly, there remains a need in the art for a method and apparatus to effectively detect vulnerabilities such as SQL and other forms of interpreter injection.